- ⚠️ Document outline headings can lag behind editor content.
- ⚠️ Active heading highlight may not match current cursor section.

1. With a markdown file open as in steps 1–2 above, `attachHandlers(payload)` mounts the
editor in `controller.ts:947-989`. The `onChange` handler at `controller.ts:961-982`
updates `state.draftContent` for the current `workspaceState` and calls
`scheduleOutlineRefresh(state)` (`controller.ts:974`), passing the current `state` object
by reference.

2. `scheduleOutlineRefresh` at `controller.ts:214-221` debounces outline updates by
clearing any existing `outlineRefreshTimer` and setting a new timeout
(`outlineRefreshTimer = setTimeout(...)` at line 237). The closure captures the specific
`state` object passed from `attachHandlers`, and after `OUTLINE_REFRESH_DEBOUNCE_MS` it
will call `applyOutlineUpdate(state, extractMarkdownOutline(state.draftContent))` at
`controller.ts:239-240`.

3. While this debounce timer is pending, `workspaceState` can be replaced by
`getState(payload)` when a new `RenderPayload` for the same file path but with different
content arrives (see autosave/save flow in suggestion 1): `buildBody(payload)` at
`controller.ts:338-369` calls `getState(payload)`; if `workspaceState.fullDocumentContent
!== cleanedContent`, `getState` reinitializes `workspaceState` to a new object at
`controller.ts:311-329`, leaving the previously captured `state` reference from
`scheduleOutlineRefresh` stale.

4. When the outline refresh timer eventually fires (`controller.ts:237-241`), it executes
`applyOutlineUpdate(state, extractMarkdownOutline(state.draftContent))` using the stale
`state` object instead of the current `workspaceState`. `applyOutlineUpdate`
(`controller.ts:222-230`) mutates that stale state's `outline` and `activeHeadingId` and
then calls `markdownTocHandle?.refresh(state.outline, state.activeHeadingId)`, causing the
document outline UI (attached in `attachHandlers` at `controller.ts:1013-1026`) to be
refreshed with headings derived from the outdated draft rather than the current editor
content and active state.

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/controller.ts
**Line:** 237:240
**Comment:**
	*Race Condition: The debounced outline refresh captures a specific `state` object and later applies it unconditionally, which can refresh the TOC with stale data after state transitions. If workspace state changes before the timer fires, this callback can update outline/UI from an outdated draft. Gate the callback to the current workspace instance (or cancel when state changes) before applying updates.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

- ❌ Markdown editor can drop unsaved text during autosave refresh.
- ⚠️ Users may lose recent keystrokes without any conflict warning.

1. Open a markdown file in the File Preview app so the host calls the `read_file` tool and
delivers a `RenderPayload` to `app.ontoolresult` at
`src/ui/file-preview/src/app.ts:247-258`. This resolves into
`renderAndSync(getEffectiveIncomingPayload(payload))`, which calls `renderApp(container,
payload, ...)` at `app.ts:143-151`.

2. In `renderApp` (`app.ts:201-239`), when `payload.fileType === 'markdown'`, the markdown
body is rendered via `renderPayloadBody` (`file-type-handlers.ts:115-122`), which in turn
calls `markdownController.buildBody(payload)` (`file-type-handlers.ts:69-80`). `buildBody`
in `controller.ts:338-369` calls `getState(payload)` at `controller.ts:339`, initializing
`workspaceState` with `fullDocumentContent` and `draftContent` equal to the cleaned
payload content (`controller.ts:311-318`).

3. The editor DOM is then wired up by `markdownController.attachHandlers(payload)` in
`renderApp` at `app.ts:241-243`, which calls `attachHandlers` in `controller.ts:940-1032`.
Inside `attachHandlers`, `mountMarkdownEditor` is invoked (`controller.ts:950-988`) with
an `onChange` handler at `controller.ts:961-982` that updates `state.draftContent`, sets
`state.dirty = value !== state.fullDocumentContent`, and calls `scheduleAutosave()`
(`controller.ts:198-205`), creating unsaved in-memory edits (`dirty === true`,
`draftContent !== fullDocumentContent`).

4. After the debounce period, `scheduleAutosave`'s timer fires and calls `saveDocument()`
at `controller.ts:699`. Inside `saveDocument`, per hunk, the code issues
`dependencies.callTool('edit_block', ...)` at `controller.ts:729-735`. Each `edit_block`
result is handled globally by `app.ontoolresult` (`app.ts:247-260`), which detects that
the tool result text lacks a read status line and therefore calls `readAndResolvePayload`
(`app.ts:164-181`). `readAndResolvePayload` uses
`markdownController.readPayload(filePath)` (`controller.ts:285-287`) to invoke the
`read_file` tool again; the resulting `RenderPayload` (with updated on-disk content for
the same `filePath`) is passed back into `renderAndSync(getEffectiveIncomingPayload(p))`
(`app.ts:508-513`), which re-invokes `renderApp` and then
`markdownController.buildBody(payload)` for the updated payload. At this point
`workspaceState` still refers to the previous in-memory state and is still `dirty`, but
the incoming `cleanedContent = stripReadStatusLine(payload.content)` now reflects the
newer on-disk content. The condition at `controller.ts:311`
(`workspaceState.fullDocumentContent !== cleanedContent`) is true, so `getState`
reinitializes `workspaceState` with `draftContent: cleanedContent` and `dirty: false`
(`controller.ts:311-318`), discarding any unsaved edits held only in the previous
`workspaceState` (including keystrokes typed while autosave/saveDocument was in progress).

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/controller.ts
**Line:** 310:317
**Comment:**
	*Logic Error: Reinitializing workspace state whenever incoming payload content differs from `fullDocumentContent` will discard in-memory draft edits and reset `dirty` to false on rerender. If the host sends a refreshed payload while the user has unsaved changes, this branch recreates state from disk content and loses the draft. Preserve the existing state when there are unsaved edits instead of recreating it purely on content mismatch.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

- ❌ File preview can open javascript: links from markdown content.
- ❌ Host executes attacker-controlled URLs without scheme allowlisting.
- ⚠️ Untrusted repositories can weaponize markdown links for abuse.

1. Open the File Preview app (`src/ui/file-preview/src/app.ts:1-200`) on any markdown
payload so that `markdownController` is constructed at `app.ts:116-144` and used to render
the document via `renderPayloadBody()` (`file-type-handlers.ts:16-23`).

2. Ensure the markdown content being rendered contains a link with a dangerous scheme,
e.g. `[Click me](javascript:alert(1))`. This content is loaded into the markdown editor
when `attachHandlers()` in `src/ui/file-preview/src/markdown/controller.ts:41-88` calls
`mountMarkdownEditor({ value: state.draftContent, ... })` at `controller.ts:51-58`.

3. In the rendered markdown editor (CodeMirror preview), hover the mouse over the `Click
me` link so the link popover is shown, then click the "Open link" button in that popover.
This triggers `handleLinkPopoverClick()` in
`src/ui/file-preview/src/markdown/editor.ts:1180-1203`, which, when `button.id ===
'link-popover-open'` (`editor.ts:1195-1197`), calls `options.onOpenLink(link.href)` with
the raw `href` value `javascript:alert(1)`.

4. The `onOpenLink` callback was wired in `attachHandlers()` (`controller.ts:59-61`) to
`navigateLink(payload, href)`. `navigateLink()` in
`src/ui/file-preview/src/markdown/controller.ts:12-31` passes this `href` to
`resolveMarkdownLink()` in `src/ui/file-preview/src/markdown/linking.ts:138-62`, which
uses `isExternalHref()` at `linking.ts:120-121` to treat any `scheme:` (including
`javascript:`) as external. For `javascript:alert(1)`, `resolvedLink.kind === 'external'`
and `navigateLink()` calls `dependencies.openExternalLink(resolvedLink.url)` or falls back
to `window.open(resolvedLink.url, '_blank', 'noopener')` (`controller.ts:25-29`), causing
the unsafe `javascript:` URL to be executed/handed off without any scheme allowlist.

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/editor.ts
**Line:** 1195:1197
**Comment:**
	*Security: Opening links directly from editor popover forwards raw `href` values (including non-http schemes) to the navigation path without scheme validation. Combined with external-link handling, this allows dangerous URLs like `javascript:` to be executed. Restrict allowed schemes (e.g., http/https/mailto) before invoking link opening.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

- ⚠️ Typing in markdown preview lags on large documents.
- ⚠️ Scrolling markdown preview stutters for big notes.
- ⚠️ Markdown preview decoration work dominates hot update path.

1. Open a large markdown file (thousands of lines) in the UI so that `attachHandlers()` in
`src/ui/file-preview/src/markdown/controller.ts:26-91` mounts the editor by calling
`mountMarkdownEditor()` at `controller.ts:36-73` with `view: 'markdown'`.

2. The markdown editor created in `mountMarkdownEditor()`
(`src/ui/file-preview/src/markdown/editor.ts:458-379`) includes the
`markdownLinePreviewPlugin` extension (`editor.ts:442-456`) which constructs its
decorations via `buildMarkdownLineDecorations(view)` at `editor.ts:260-440`.

3. On each document edit or viewport scroll, the plugin `update()` method at
`editor.ts:449-452` is called with `docChanged` or `viewportChanged` true; it recomputes
`this.decorations = buildMarkdownLineDecorations(update.view)` for every such update.

4. Inside `buildMarkdownLineDecorations()`, `collectSpanningWrapperRanges()` at
`editor.ts:284-333` first converts the entire document to a string (`const source =
view.state.doc.toString();`) and linearly scans it to compute `spanningInlineRanges`
(`editor.ts:335`), and then for each visible line in `view.visibleRanges` it filters these
global ranges (`markerRanges.push(...spanningInlineRanges.filter(...))` at
`editor.ts:424`) and builds per-line decorations. On large documents, this
O(document_size) scan and per-visible-line filtering on every keystroke or scroll causes
measurable typing and scrolling lag in the markdown preview editor.

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/editor.ts
**Line:** 335:452
**Comment:**
	*Performance: Decoration rebuilding does a full-document scan on every document or viewport change and then re-filters those global ranges for each visible line, which creates heavy O(document_size × visible_lines/ranges) work in a hot path. On large markdown files this can cause typing and scrolling lag. Restrict wrapper scanning to visible ranges or maintain incremental state instead of recomputing globally each update.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

- ⚠️ Editing existing wiki links via popover has no effect.
- ⚠️ Users must re-search/reselect file to update wiki link.
- ⚠️ Markdown note editing UX is inconsistent between URL and wiki links.

1. Open any markdown file in the UI so that the markdown editor is mounted via
`attachHandlers()` in `src/ui/file-preview/src/markdown/controller.ts:26-36`, which calls
`mountMarkdownEditor()` at `controller.ts:36-73` with `view: state.editorView` set to
`'markdown'`.

2. In the markdown editor created by `mountMarkdownEditor()`
(`src/ui/file-preview/src/markdown/editor.ts:458-379`), ensure the document contains a
wiki link such as `[[Some/Note#heading|Alias]]`; the inline link parsing for wiki links is
handled by `findMarkdownLinkInLine()` at `editor.ts:937-973`.

3. Hover the wiki link in the markdown editor until the link popover appears, then click
the "Edit link" button; this triggers `handleLinkPopoverClick()` at `editor.ts:1266-1285`,
which calls `openLinkModalForSelection(existingLink)` at `editor.ts:992-1024` with
`existingLink.kind === 'wiki'`.

4. Observe that `openLinkModalForSelection()` switches the modal to file mode and
explicitly clears `selectedLinkItem` and `linkSearchResults` (`editor.ts:999-1021`), so
when you click "Insert" in the modal, `handleLinkApply()` at `editor.ts:1026-1066` runs
the `else if (selectedLinkItem)` wiki-link branch only if a file search result is
selected. Because `selectedLinkItem` is always `null` when editing an existing wiki link
(unless you manually run a new search and select a result), the wiki-link branch is
skipped and only `closeLinkModal()` at `editor.ts:1066` executes. The modal closes without
dispatching any `view.dispatch()` changes, so alias/heading edits to an existing wiki link
are silently dropped.

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/editor.ts
**Line:** 1046:1066
**Comment:**
	*Logic Error: Editing an existing wiki link through the link modal can silently do nothing because apply only executes when `selectedLinkItem` is set, but opening the modal for an existing link clears that selection. This makes "edit link" fail unless the user re-runs search and re-selects a file. Pre-populate the selected item from the existing wiki link (or allow apply when an existing link is being edited).

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

This is an **Architect / Logical Review** comment left during a code review. These reviews are first-class, important findings — not optional suggestions. Do NOT dismiss this as a 'big architectural change' just because the title says architect review; most of these can be resolved with a small, localized fix once the intent is understood.

**Path:** src/ui/file-preview/src/markdown/controller.ts
**Line:** 1038:1051
**Comment:**
	*HIGH: In fullscreen markdown edit mode, the table of contents no longer tracks the active heading while scrolling because `attachDocumentOutline` still relies on DOM heading elements with `id`s, but the new CodeMirror-based editor no longer renders such elements. As a result, the scroll listener in `attachDocumentOutline` never finds headings and the TOC highlight becomes stale unless the user explicitly clicks a TOC item.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
If a suggested approach is provided above, use it as the authoritative instruction. If no explicit code suggestion is given, you MUST still draft and apply your own minimal, localized fix — do not punt back with 'no suggestion provided, review manually'. Keep the change as small as possible: add a guard clause, gate on a loading state, reorder an await, wrap in a conditional, etc. Do not refactor surrounding code or expand scope beyond the finding.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

- ❌ Wikilink edit popover can't update existing link.
- ⚠️ Alias changes silently discarded when editing wikilinks.
- ⚠️ Markdown editor link UX inconsistent between URL, wiki.

1. Open a markdown file that contains an existing wikilink (e.g.
`[[notes/Example#heading|Alias]]`) in the UI; `attachHandlers()` at
`src/ui/file-preview/src/markdown/controller.ts:26-36` mounts the markdown editor via
`mountMarkdownEditor()` at `src/ui/file-preview/src/markdown/editor.ts:458-469` with
`view: 'markdown'` and `currentFilePath` set.

2. In the editor, hover the existing wikilink so `handleLinkMouseMove()` at
`editor.ts:1248-1259` finds it via `findMarkdownLinkAtPosition()` (`editor.ts:976-981`)
and `showLinkPopover()` (`editor.ts:1201-1246`) displays the popover containing "Edit
link" and "Open link" buttons.

3. Click the "Edit link" button; `handleLinkPopoverClick()` at `editor.ts:1266-1283`
detects `button.id === 'link-popover-edit'` and calls `openLinkModalForSelection(link)`
(`editor.ts:992-1024`), which sets the selection to the link (`editor.ts:996-998`), opens
the modal, switches to file mode for wikilinks via `updateLinkMode(existingLink?.kind ===
'wiki' ? 'file' : 'url')` at `editor.ts:1001`, but then clears all file selection state by
setting `linkSearchResults = []`, `selectedLinkItem = null`, and resetting the results
message at `editor.ts:1019-1021` before calling `setLinkHeadingOptions()` and
`renderLinkResults()` at `editor.ts:1022-1023`.

4. Without typing a new search or clicking any search result (so `selectedLinkItem`
remains `null`), edit the alias or just click "Insert"; `handleLinkApply()` at
`editor.ts:1026-1065` runs with `linkMode === 'file'` but skips the wikilink update branch
because it is guarded by `else if (selectedLinkItem)` at `editor.ts:1046`, resulting in no
`view.dispatch()` call and no text changes, while `closeLinkModal()` at
`editor.ts:1026-1067` is still invoked, causing the modal to close and the user's edit to
be silently discarded.

This is a comment left during a code review.

**Path:** src/ui/file-preview/src/markdown/editor.ts
**Line:** 1001:1023
**Comment:**
	*Logic Error: Editing an existing wikilink opens file mode but clears all selected file state, while apply only executes the wikilink branch when a file is selected. If the user clicks "Insert" without re-searching and reselecting, the operation silently no-ops instead of updating the link, breaking the edit flow. Prepopulate `selectedLinkItem` for existing wikilinks or allow apply to update from parsed existing link data.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix